Understanding and Using DICOM, the Data Interchange Standard for Biomedical Imaging

specifies a non-proprietary data interchange protocol, digital image format, and file structure for biomedical images and image-related information. The fundamental concepts of the DICOM message protocol, services, and information objects are reviewed as background for a detailed discussion of the functionality of DICOM; the innovations and limitations of the Standard; and the impact of various DICOM features on information system users. DICOM addresses five general application areas: (1) network image management, (2) network image interpretation management, (3) network print management, (4) imaging procedure management, (5) off-line storage media management. DICOM is a complete specification of the elements required to achieve a practical level of automatic interoperability between biomedical imaging computer systems—from application layer to bit-stream encoding. The Standard is being extended and expanded in modular fashion to support new applications and incorporate new technology. An interface to other Information Systems provides for shared management of patient, procedure, and results information related to images. A Conformance Statement template enables a knowledgeable user to determine if interoperability between two implementations is possible. Knowledge of DICOM’s benefits and realistic understanding of its limitations enable one to use the Standard effectively as the basis for a long term implementation strategy for image management and communications systems. n J Am Med Inform Assoc. 1997;4:199–212. Affiliations of the authors: Division of Medical Informatics, Department of Community and Family Medicine, Duke University Medical Center, Center for Outcomes Measurement, Duke University Medical Center, Cognitive Science Branch, Lister Hill National Center for Biomedical Communication, National Library of Medicine, United States National Institutes of Health (WDB); Department of Radiology, Hospital of the University of Pennsylvania (SDH); Philips Medical Systems (FWP); Merge Technologies (DEV). Support for this work was provided by the National Library of Medicine, Duke University, the American College of Radiology, and the College of American Pathologists. Correspondence and reprints: W. Dean Bidgood, Jr., MD, Box 3321, Duke University Medical Center, Durham, NC 27710. E-mail: [email protected] Received for publication: 11/15/96; accepted for publication: 1/16/97. The Digital Imaging and Communications in Medicine DICOM Standard, (originally published as the American College of Radiology—National Electrical Manufacturers Association Standard for Digital Imaging and Communications in Medicine; now maintained by the multi-specialty DICOM Standards Committee) specifies a nonproprietary data interchange protocol, digital image format, and file structure for biomedical images and image-related information. A DICOM Interface involves far more than a simple hardware specification for something like an electric outlet or parallel printer cable. In fact, DICOM does not define a ‘‘plug and socket’’ at all; it defines the form and flow of the electronic messages that convey images and related information between computers. At the time of this writing, the DICOM Standard is a thirteen volume set of engineering information that is used by engineers as a blueprint for the information structures and procedures that control the input and output of data from medical imaging systems. If prop200 BIDGOOD ET AL., Understanding and Using DICOM erly designed (to the DICOM specifications), properly configured and used appropriately, equipment having a DICOM interface will communicate reliably with other DICOM equipment. Since DICOM interfaces are available for nearly every model of diagnostic imaging equipment, imaging system implementers now have the freedom to select equipment based on merits rather than on proprietary considerations. In spite of the proven effectiveness of the DICOM Standard and the increasing availability of commercial equipment that uses DICOM, there is still misunderstanding of the benefits of DICOM and the real impact of DICOM on the imaging system user. In-depth understanding of the DICOM Standard requires some familiarity with medical imaging, linguistics/semantics, computer science and engineering. Fortunately, a working knowledge of the practical aspects of DICOM will be sufficient for most readers. With knowledge of the main concepts and realistic expectations, one will be equipped either to consult with appropriate experts or to pursue further independent study. Our goal is to answer three main questions: n For practical purposes, what should one know about DICOM? n In what ways does DICOM directly impact one’s day-to-day work? n How can one take advantage of the benefits of DICOM? For Practical Purposes, What Should One Know About DICOM? Overview of the DICOM Standard DICOM provides detailed engineering information that can be used in interface specifications to enable network connectivity among a variety of vendors’ products. The Standard describes how to format and exchange medical images and associated information, both within the hospital and also outside the hospital (e.g., teleradiology, telemedicine). DICOM interfaces are available for connection of any combination of the following categories of digital imaging devices: (a) image acquisition equipment (e.g., computed tomography, magnetic resonance imaging, computed radiography, ultrasonography, and nuclear medicine scanners); (b) image archives; (c) image processing devices and image display workstations; (d) hard-copy output devices (e.g., photographic transparency film and paper printers). DICOM is a message standard (i.e., a specification for interchange of information between computer systems). DICOM is a comprehensive specification of information content, structure, encoding, and communications protocols for electronic interchange of diagnostic and therapeutic images and image-related information. Some other healthcare data interchange standards specify only a subset of the properties that impact interoperability. The Health Level Seven (HL7) Standard specifies a message model, but provides only an abbreviated specification for network communications. The CEN/TC 251/PT3-033 (European Standardization Committee: Technical Committee for Healthcare, Project Team 22) Request and Report Messages for Diagnostic Service Departments’’ 3 document specifies a semantic data model and model-based compositional rules for messages, but only partial guidelines for electronic document interchange. Thus, the HL7 and CEN/TC 251 specifications leave major communications issues unresolved. Implementors depend on bilateral negotiation between information system vendors to determine parameters for the unspecified details. DICOM is a complete specification ‘‘from top to bottom’’ of the elements required to achieve a practical level of automatic interoperation. DICOM Protocol, Services, and Objects DICOM specifies a protocol for message exchange (Fig. 1). The DICOM message protocol provides the communications framework for DICOM services. The DICOM protocol is compatible with Transmission Control Protocol and Internet Protocol. This enables DICOM application entities to communicate over the Internet. The DICOM services fall into two groups: composite and normalized. The composite services were designed for compatibility with previous versions of the ACR-NEMA Standard. They were originally intended for storage (C-STORE), query (C-FIND), retrieval (C-GET), and transfer (C-MOVE) of images. However, the composite services are also useful for other types of information, such as interpretation reports. Note that the composite group does not include an ‘‘update’’ service. This omission is intentional. The architects of the original ACR-NEMA Standard elected to omit ‘‘update’’ to reduce the possibility of altering an image record. Thus, the composite services are optimized for image interchange. However, this optimization limits the usefulness of the composite services for other domains. Interpretation data interchange is an area in which the composite services are useful. Since alteration of medical records is, of course, forbidden, amendments of original interpretation reports are typically issued as new documents. This business model translates precisely into the composite service paradigm. Journal of the American Medical Informatics Association Volume 4 Number 3 May / Jun 1997 201 F i g u r e 1 This figure depicts three different implementations of the DICOM protocol scheme. A DICOM network connection exists between the application software programs (peer DICOM application entities) of imaging devices. In configuration 1 the application software generates the DICOM command request (RQ) and command response (RSP) messages that flow from one device to another. In configuration 2 a separate DICOM Message Service Element (DIMSE) protocol machine generates the command messages on behalf of the application software. The DIMSE protocol machine is the DICOM service provider (DSP). The application software is the DICOM service user (DSU). Configuration 3 uses separate modules for all communications and applications functions. A second layer of DICOM messages is used within each device. These are the DIMSE service primitives: the Request Primitive (REQP), Indication Primitive (INDP), Response Primitive (RSPP), and Confirmation Primitive (CFMP). A freestanding DSU module generates the DIMSE service primitives on behalf of the application software. Even though the protocol machine and DICOM service user module may be implemented in various ways, the external command messages are identical for all configurations. The normalized services were designed to provide broader information management functionality. Note that the name ‘‘normalized’’ does not relate to the normalization of databases. The normalized services were envisioned for use with records representing the properties of a single real-world entity, whereas the composite services were used initially only with documents (images) that contain information derived from more than one real-world entity (e.g. pixel data, equipment, and patient identification number). The normalized services support the basic information management operations: create (N-CREATE), delete (N-DELETE), update (N-SET), and retrieve (N-GET). In addition, domain-specific operations (N-ACTION) such as ‘‘print a sheet of film’’ can be defined. A notification service (N-EVENToNOTIFY) is also specified in the normalized group. In spite of its flexibility, the normalized service group has some notable limitations. The update service (N-SET) has limited usefulness for the ‘‘sequence of items’’ datatype. N-SET must update an entire sequence rather than an individual data element within a sequence. The normalized group also lacks a query service. This glaring omission is the result of the lack of industry consensus on network query protocols at the time the standard was written. For the Information System–Imaging System (ISIS) interface, this limitation is ameliorated by the Basic Modality Worklist service-object pair (SOP) class (see the definition of SOP class in the next paragraph). The Modality Worklist SOP Class specifies a composite query service for retrieval of demographic and scheduling information by imaging devices. Real-world entities (e.g., images, procedures, or interpretation reports) are represented in the DICOM semantic data model by templates of attributes. The formal specifications of these templates are documented in the DICOM information object descriptions (IODs). An IOD is an abstract description of a class of entities. An ordered set of values representing the properties of one member of a class may be operated upon by one or more DICOM composite or normalized services. A DICOM Service-Object-Pair (SOP) Class specifies the combination of an IOD and the set of services (DIMSE service group) that are useful for a given purpose. SOP Classes (such as the Basic Modality Worklist SOP Class) are specified within Service Classes according to their purpose. SOP Classes that use composite services are Composite SOP Classes. Normalized SOP Classes use normalized services. An instance of a SOP Class is known as a service-objectpair (SOP) instance. Composite objects and normalized objects are synonyms for composite and normalized SOP instances. DICOM object terminology is eclectic, but it is certainly also precise. For brevity, DICOM SOP Classes are often referred to as objects or information objects. Note, however, that DICOM objects are ‘‘static’’ objects. They are passive information structures that may be operated upon by external methods. They are not self-contained software components capable of polymorphism, encapsulation, and inheritance. Their design suits their purpose. DICOM SOP classes (and instances) are useful abstractions for data interchange. They are not application components, per se. The data structure of DICOM SOP classes maps well to the data structures of software components and DIMSE service groups map to object methods. Message transactions using DICOM begin with association establishment. A DICOM association is a com202 BIDGOOD ET AL., Understanding and Using DICOM F i g u r e 2 Image transfer. The scanner initiates routine image transfers. DICOM does not specify the behavior of the scanner device; the scanner may begin sending images whenever it is ready. This may be done automatically as individual images are completed during a scan procedure, or it may be done at some later time after all images of a procedure have been acquired and the scanner operator has initiated the transfer by activating a ‘‘send images’’ key on the scanner console. When the scanner is ready to send, it sends images one by one to the workstation. The scanner initiates a DICOM communications session (called an ‘‘association’’) with the workstation for the transfer of each image. Various details are negotiated during association establishment, so that the workstation can prepare to handle the image that it is about to receive. F i g u r e 3 Image query and retrieval. Acting on a specific request entered by the user a the workstation console, the workstation software provides to the scanner a query request message, asking for image records that have values matching a set of query keys. The scanner returns a list of matching images. Now, having knowledge of the identification numbers of the images, the workstation user selects the pertinent images from the displayed list and enters a ‘‘retrieve images’’ command at the keyboard. The workstation software then sends a message to the scanner, listing the image identification numbers and requesting the scanner to send the images. The scanner sends the requested images, one at a time, to the workstation, using the DICOM Storage Service, as illustrated in Figure 2. munications session involving a pair of peer DIMSEservice-users (see Fig. 1). In other words, a DICOM association is an open channel for message exchange between two devices that use the DIMSE protocol machine (software) to generate and receive DICOM messages. During the association establishment process, the two devices arrive at a shared understanding of the information structures that will be exchanged and the services that will be invoked (i.e. the abstract syntax). Additional parameters essential to interoperability, such as the byte order and data compression method are also negotiated (i.e. the Transfer syntax). Associations are managed by a software process known as the Association Control Service Element (ACSE). The DICOM protocol specifies the coordination of ACSE and DIMSE functionality. DICOM Service Classes support five general application areas. Each will be described separately in the sections that follow. The Service Classes enable: n Network image management n Network image interpretation management n Network print management n Imaging procedure management n Off-line storage media management Network Image Management DICOM network image management supports two general contexts of interaction between imaging devices: push mode and pull mode. The basic service is ‘‘push’’ mode, in which one device simply sends images to another device over a computer network (Fig. 2). ‘‘Pull mode’’ is a more elaborate two-stage process that allows the user first to query a remote device and then to retrieve selected images (Fig. 3). DICOM network image management provides two important operational capabilities that are lacking in systems that use generic file transfer protocols. These capabilities are enabled by the explicit semantics of DICOM. Explicit semantics means ‘‘shared understanding between client and server of the information structure of objects’’ as well as a shared understanding of methods (functions or services). Having a standard template (information object description) of properties of each type of image (including a small sample of associated demographic and procedure-related information), the receiving device is aware of the information structure of the image before receiving it. This shared understanding enables storage and retrieval of sets of images using a clinically relevant indexing system based on image attributes rather than on a file name alone. With DICOM it is possible for a device to search for images using a meaningful query key such as the patient’s name. Once received the image can be stored in context with others that relate to it. Explicit semantics also enables software processes to allocate appropriate resources for management of each class of DICOM object. Five DICOM network image management services (transaction types) are specified in the Storage, Query/Retrieve, and Storage Commitment Service Journal of the American Medical Informatics Association Volume 4 Number 3 May / Jun 1997 203 F i g u r e 4 Reliable storage. Storage Commitment is an extension of the basic DICOM Storage Service illustrated in Figure 2. After sending a set of images to an archive device, the scanner operator sends a Storage Commitment Request message to the archive. The purpose of the message is two-fold. First, the message requests the archive device to verify that all of the intended images have been received. Second, the message requests that the archive device assume responsibility for the safekeeping of the images, so that the scanner can, for example, delete its local copies of the images. If all is well, then the archive returns a confirmation message to the scanner. If there is a problem with one or more images or with the entire operation, then the archive device returns an appropriate error message to the scanner operator. Classes. The services specified in these Service Classes are defined only for DICOM composite objects. The Storage Service Class specifies the C-STORE service. C-STORE enables a client to transfer (push) a DICOM object to a server for storage. In the negotiation that occurs between client and server processes at the establishment of a DICOM C-STORE association (session), the client notifies the server of the class of object that it proposes to transfer and the server confirms that it supports that information object class. A unique service class identifier, the (Storage) SOP Class UID, is defined for storage of each information object class so that the server can allocate appropriate resources. The Query/Retrieve Service Class specifies the CFIND, C-MOVE, and C-GET services and the DICOM query/retrieve information model. The C-FIND, CMOVE, and C-GET services are specified in the context of a specific view of the query/retrieve information model that defines the semantics of queries and constrains the set of keys. The desired view of the query/retrieve information model is selected by sending the appropriate (Query/Retrieve) SOP Class UID in the query request message. The C-FIND service enables a client to query a server for matches against a template of key values. C-FIND also enables the server to return the object instance identifiers of any matching records to the client. The C-MOVE service enables a third party to initiate the transfer of DICOM objects between two locations. For example, an imaging workstation may use C-MOVE to invoke the transfer of DICOM image objects from a scanner to an archive. The C-GET service is essentially an inverse C-STORE. An application process uses C-GET to retrieve (pull) objects that match a set of key values. Since 1995, all of the major diagnostic imaging modalities have been standardized. This list includes computed tomography (CT), magnetic resonance imaging (MRI), computed radiography, ultrasonography, nuclear medicine, radiofluoroscopy, x-ray angiography, and secondary capture (for digitized video). The DICOM Visible Light (VL) image specification (for endoscopy, microscopy, and photography) has been placed under revision control and is available for trial implementation. Network image management is the most widely implemented DICOM service. Products conforming to DICOM network image management are available from many vendors. The Storage Commitment Service Class specifies the fifth DICOM network image management service. Storage Commitment enables an image source (most often an acquisition device) to obtain a commitment from an image storage device that images have been stored reliably (Fig. 4). Typically, two types of devices provide this service: long-term and short-term storage devices. Long term storage devices (image archives) commit to store images permanently. Short-term storage devices commit to retain images only for a limited time. For example, an acute-care hospital might use a high-throughput, medium-capacity storage device as an image distribution center to minimize waiting time for images of hospitalized patients. The intermediate storage device might later transfer the images to lowthroughput, high-capacity optical storage media for permanent archival after patient discharge from hospital. The short term and the long term storage devices both commit to storage images reliably. However, they commit to different values of storage duration, retrieval latency (delay), and storage capacity. From the user’s perspective, it is essential that devices claiming to provide reliable storage actually do so. To conform to the DICOM Storage Commitment Standard, devices must reliably store images and related information for at least a specified minimum duration and must meet or exceed other performance parameters stated in a DICOM Conformance Statement (see Specifying DICOM, below). Network Image Interpretation Management Supplement 23 of the DICOM Standard defines a network image interpretation object (the Structured Interpretation SOP Class) and a corresponding interpretation storage service. At the time of this writing, the specification is under a formal revision control procedure and it will be frozen for trial implementation. 204 BIDGOOD ET AL., Understanding and Using DICOM